The present invention relates generally to the management of computing devices, and more particularly to managing alias devices in a computing environment to optimize processing of I/O requests.
Data storage devices are used for storing and retrieving digital information. Often input/output (I/O) requests are to be executed by a storage controller to the data storage devices in order to perform necessary read/write operations for a particular process. Typically, in a multi-system environment, a large number of incoming I/O requests can be processed by base devices, alias devices, and eventually executed by the storage controller. For example, in System z®, each I/O device is defined to the I/O configuration and is represented by a sub-channel in a processor and a unit address in the storage controller. When an I/O request is issued to a device, only one I/O request can be active on the sub-channel at a time. Therefore, if multiple I/O requests for a device arrive at the same time, a portion of those I/O requests may be queued internally by the operating system and accumulate I/O queuing time delay. In System z® environments, parallel access volumes (PAVs) may be implemented to address this queueing time delay. With PAV, one or more alias devices can be configured that are used to perform I/O requests to the base device, when the sub-channel for the base device is busy with another I/O request. Alias devices do not represent an actual logical volume on the storage controller; rather they simply provide a pathway (i.e., a sub-channel) that allows System z® to do more than one I/O operation in parallel to the same base device.
Typically, there are a number of models used to manage PAV aliases. The most efficient model with regard to performing multiple I/O requests is called HyperPAV. Prior to System z® implementing a HyperPAV model, alias devices were bound to a particular base device for a period of time and moved when needed to another base device. However, aliases were moved infrequently and only after the workload experienced I/O queuing delays. Usually, with a HyperPAV model, alias devices are put into a pool and used only for the duration of an I/O request and then they are put back into the pool. This allows less alias devices to be defined since their usage is managed more efficiently.
In one example where a HyperPAV model is implemented, base devices may experience delays when performing a large number of queued I/O requests. In this instance, alias devices may be more likely to be selected and assigned to the base devices that are experiencing processing delays, which may result in unwarranted consumption of alias devices in the alias device pool. Accordingly, the consumed alias devices will be unavailable to perform I/O requests for base devices that are not experiencing processing delays.
For example, for disaster recovery purposes, an Extended Remote Copy (XRC) process may be implemented to copy data asynchronously from a local site to a remote site. In this instance, the remote site may read data from a local device in a local site over a long distance link. Furthermore, data may be written to the local device from the local site at a faster rate than a remote device in the remote site can read from the local device over the long distance link. Accordingly, a storage controller that controls the local device will inject delays for write requests that are being issued from the local site. This delay, known as XRC pacing delay, allows the remote site to catch up on performing read requests for copying data asynchronously.
In another example, a storage controller with a hard disk drive (HDD) may process a write operation of an I/O request. Furthermore, the write operation is processed by first copying data to be written to a non-volatile storage (e.g., cache memory within the storage controller) and then eventually de-staging the data to be written to a storage device. In this instance, if a large number of write operations, or a large amount of data for each write operation is generated, then the storage controller may not be able to synchronously process the write operations at the rate in which write operations are being generated, since it is not able to de-stage the data already in non-volatile storage fast enough. Typically, in this manner, a processing delay may occur for write operations, and can affect a process for a subset of base and alias devices to perform necessary I/O requests.
In yet another example, a storage controller may limit access to its resources (memory, CPU, disk drives etc.) based on an I/O request importance level. Usually, if there is contention for its resources, the storage controller may internally delay lower importance I/O requests to allow higher importance I/O requests to get access to those resources.
In yet another example, a storage controller may implement storage tiers, such that data not recently referenced by storage computer system may be migrated to slower storage tiers. In this instance, once the data is moved to a slower storage tier, additional time may be required to retrieve the data the next time the data is referenced. For example, the storage controller may implement a first storage tier which may involve delaying I/O requests for an amount of time it takes to spin a disk of a storage device (i.e., a platter of a HDD). In another example, the storage controller may implement a second storage tier which may involve delaying I/O requests for an amount of time it takes to retrieve data from a tape storage device. Accordingly, this delay as a result of implementing storage tiers can affect a process for a subset of base and alias devices to perform necessary I/O requests.